Designing Scenarios for Controller-in-the-Loop Air Traffic 

Simulations 


Michael Kupfer* * * , Joey Merced, Christopher Cabral^, and Todd Callantine § 
San Jose State University Research Foundation, Moffett Field, CA, 94035 


Well prepared traffic scenarios contribute greatly to the success of controller-in-the-loop 
simulations. This paper describes each stage in the design process of realistic scenarios based 
on real-world traffic, to be used in the Airspace Operations Laboratory for simulations 
within the Air Traffic Management Technology Demonstration 1 effort. The steps from the 
initial analysis of real-world traffic, to the editing of individual aircraft records in the 
scenario file, until the final testing of the scenarios before the simulation conduct, are all 
described. The iterative nature of the design process and the various efforts necessary to 
reach the required fidelity, as well as the applied design strategies, challenges, and tools used 
during this process are also discussed. 


I. Introduction 

H uman-in-the-loop (HITL) simulations are an integral part of the Air Traffic Management (ATM) Technology 
Demonstration- 1 (ATD-1). 1 ATD-1 is an effort to operationally demonstrate the feasibility of high throughput 
efficient arrival operations during peak traffic conditions, using NASA-developed technologies. The HITL 
simulations of this project help to assess the performance of the integrated software technologies and, to assess the 
performance of the human working with those systems. 

The Airspace Operations Laboratory (AOL) has a long history in conducting controller-in-the-loop simulations 
using the Multi- Aircraft Control System (MACS) as its primary simulation environment. 2 The AOL recently 
conducted a series of HITL simulations in support of ATD-1. 3, 4 In any successful HITL simulations of an ATM 
environment, a set of realistic traffic scenarios is required to provide the controllers with a detailed image of the 
real-world operations. Achieving a high realism of the modeled traffic, in terms of loads in sectors, loads on routes, 
carrier-aircraft type-equipage combinations, filed flight plans, traffic patterns, etc., enables the controllers and pilots 
to execute their tasks in the same way as they would in the real world. In general, if the realism of the simulation 
environment and the simulated traffic is high, researchers will be able to obtain a reasonable impression of how the 
operations might behave when the ATD- 1 systems are transferred to, and tested in an operational setting. 

In preceding ATD-1 HITL simulations the Airborne Spacing for Terminal Arrival Routes (ASTAR) -equipped 
Aircraft Simulator for Traffic Operations Research (ASTOR) simulator (Ref. 5), containing one of the ATD-1 
technologies, was integrated into the simulation environment. The complexity of the scenario design process 
increased: flights operated by the ASTOR simulator needed strategic placement in the arrival sequence, and required 
careful coordination between two file formats: that of the MACS traffic scenarios, and a specific ASTOR scenario 
format. The two scenario files needed to interleave seamlessly when running the combined system in a HITL 
simulation. Because these early simulations focused on the integration of the ATD-1 systems, the scenarios design 
was less constrained initially. For example, not all the traffic types needed to be simulated, and flight initialization 
positions and routes were eligible for editing, as long as the general characteristics of the traffic were maintained. 

Upcoming ATD-1 HITL simulations will investigate the system performance. An increased level of fidelity of 
the traffic scenarios is necessary to support this goal. The experiments will simulate more sectors and additional 
traffic, such as over- flights, departure traffic, satellite arrivals, and satellite departures. Also, a range of aircraft 
performance groups will be represented in the scenarios (i.e., jets, high- and low-performing turbo-prop aircraft and 
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piston aircraft). The distributions of the traffic on the various routes, and the corresponding air carrier and aircraft 
type mixes must match those in the real world. The positions of the arrival aircraft need to match as close as possible 
to the positions from the recording of actual traffic. A thorough vetting process must then follow, one that includes 
lab tests, full scale simulation shakedowns and subject matter expert interviews. This helps to mitigate scenario 
artifacts, such as unrealistic aircraft routing, incorrect ownership, immediate conflicts upon simulation initialization, 
unrealistic speeds and altitudes, etc. 

The next section of this document first informs about other existing scenario generation software and work on 
the development of traffic scenarios. To prepare the ground for the current work it then states objectives and gives 
an overview of the traffic scenario design process that was followed. In the end details of the airspace are presented. 
The section Scenario Design guides step-by-step through the individual scenario development stages. At first, 
insights of the data acquisition are laid out, followed by details of the main scenario editing. The section concludes 
with information on testing and validation. To explain the actual outcome of the scenario-building effort a variety of 
metrics for one of the scenarios are presented. The document ends with a conclusion highlighting the essential 
scenario building steps and insights gained during this process, discussing key problems that were encountered, and 
pointing out where room for improvement was found. 

II. Background 


A. Related work 

Building traffic scenarios for fast- or real-time simulations have long been an integral part of the overall 
simulation process. It may take considerable amounts of time to construct traffic files that meet the needs of the 
simulation. Depending on the desired complexity of the traffic and airspace, and whether the simulation will be 
conducted in fast-time or real-time, scenarios may be compiled manually, partially automatically, or even 
completely automatically. Even with automatically-generated scenarios, often there is some degree of manual 
editing still required. 6, 7 

The AvScenario software is described as a tool which automates many scenario-building steps. 6 It is able to 
automatically read a variety of existing flight data that, after import, can be modified in several ways. Using a 
graphical interface, routes as well as flight path start- and end points can be modified by simple drag and drop 
actions. It also provides direct text-editing features without the need for the user to employ other text-editor or 
spread-sheet software. The software also provides the functionality to easily modify adaptation data such as navaids, 
routes and other airspace features like special use airspace areas. An AvScenario traffic file can be exported in the 
generic extensible markup language (XML) format, or into specific simulator formats. For the latter, an explicit 
mapping of the individual scenario information elements is required. 

In the AwSim trajectory simulation software scenarios provide typical information, such as latitude, longitude, 
altitude, and time to simulate flights as a population of 4-dimensional trajectories. Other parameters included are 
aircraft types, weights, and fuel bum values. AwSim uses an agent-based model employing Monte-Carlo algorithms 
to generate the 4-dimensional trajectories, and can work from live flight data feeds such as Aircraft Situation 
Display to Industry (ASDI). 8 

Other scenario-building software takes advantage of a genetic algorithm to modify real-world traffic by time- 
shifting the flights such that aircraft-to-aircraft encounters and conflicts are being generated. 9, 10 Also, European Air 
Navigation Service Providers and universities are employing fast-time and real-time simulations for their research, 
for which traffic scenarios are required: a software application called TRAffic Modeller (TRAMO) was created to 
aid users in building traffic scenarios for usability studies. 11 It has manual editing capabilities and also provides 
batch processing functions to import traffic data from external sources, such as Reorganized ATC Mathematical 
Simulator (RAMS) or Total Airspace and Airport Modeler (TAAM). Similar to AwSim it also provides drag-and- 
drop editing of the flight trajectories. ATACs Sky View software can use real-world data to build traffic scenarios for 
controller training. 12 

B. Traffic Scenario Objective 

The objective of the scenario design task was to create traffic scenarios that mirror real-world high-demand 
arrival flows under realistic wind conditions, for all airport flow configurations. Recordings of live traffic served as 
the basis for the scenarios, which were intended to be used for various simulations within the ATD-1 effort, thereby 
increasing the comparability of simulation results across the experiments conducted by the different research groups. 
The scenarios were first designed to support the requirements of the Controller Managed Spacing (CMS) ATD-1 
(CA) experiment series. A critical goal was to develop traffic scenarios that captured the original characteristics of 
the live traffic recordings as best as possible, with as few differences from the live recording as possible. 
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C. Process Overview 

The scenario design process that was used followed the development flow illustrated in Ref. 6, but can be broken 
down into three main steps. One, the scenario design preparation, which includes real-world traffic identification, 
acquisition and the preparation of the raw traffic data for output. Two, the main scenario design. This step includes 
initial scenario editing and cleanup, the main aircraft record set adjustment and, building the ASTOR scenarios. The 
third step includes scenario testing, validation and fine tuning. The three steps are described in the subsequent 
paragraphs in more detail. 

The overall process relied on two main software applications: the Trajectory-Based Route Analysis and Control 
(TRAC) tool, and the Multi Aircraft Control System (MACS), both developed at NASA Ames. TRAC is an air 
traffic visualization, graphical design and analysis software that supports the iterative design of next generation 
(NextGen) air traffic management concepts. 7 ’ 13 It provides an airspace graphical user interface onto which default 
and custom airspace adaptation data, simulation data, and other analysis features can be overlaid using individually 
controllable layers. Several tools and functions provide extensive data manipulation and analysis capabilities. TRAC 
supports data sources from MACS and other research tools. It is able to load, visualize and filter raw data from live 
traffic recordings, and output the relevant data from the identified periods of interest in a format that can be 
understood by the MACS software. 

MACS provides an environment for rapid prototyping, human-in-the-loop air traffic simulations, and evaluation 
of the current and future air/ground operations. 2 It is the simulation platform used for the ATD-1 HITL studies. It 
includes a powerful scenario editor that provides a synchronized graphical (Scenario Editor) and tabular (AC Table 
Editor) representation of the traffic scenario. While users can edit all elements necessary to simulate a flight directly 
in the table, they can also modify aspects of an aircraft trajectory (e.g., initialization position) by drag-and-drop 
actions in the graphical interface. The scenario editor provides several automated functions, such as ‘auto-update’ 
which re-computes the value of one flight parameter based on the modified value of another. For example, the target 
waypoint (i.e., the next downstream waypoint) is linked to, and updated depending on, the initialization point of a 
flight: if the initialization point changes, the target waypoint can update automatically. The scenario editor also 
provides an error-checking functionality. It typically checks against aircraft performance values and rules for route 
definition. Additional scenario editor tools include: trajectory manipulation functions (i.e., functions to quickly alter 
altitude, initialization time and initialization position), load graphs (e.g., indicating the predicted traffic count in 
sectors) and conflict highlighting tools (for identifying aircraft- to-aircraft or aircraft- to-weather encounters). 

Traffic scenarios for ATD-1 were designed to simulate operations at and around Phoenix International Airport 
(KPHX), because it shares characteristics of likely ATD-1 demonstration sites, including established RNAV OPDs. 
After an examination of live traffic recordings, several peak arrival demand periods were identified based on their 
peak terminal area entry rates. They reflect different times of the year and times of the day, and exhibit different 
arrival-fix distributions. In the end, the two maximum arrival rushes were selected, which included traffic pushes 
from over three of the four arrival directions. In one case the arrival rush occurs during an east- flow airport 
configuration, whereas in the other case the arrival rush occurs during a west-flow airport configuration. 

Each traffic scenario is comprised of four main aircraft groups: the first group contains flights that are members 
of an identified peak arrival rush (subsequently referred to as arrivals). The second group of aircraft includes 
additional arrival flights that arrive after the members of the peak period (subsequently referred to as extended 
arrivals). These aircraft served to ensure that Center and Terminal Radar Approach Control (TRACON) Feeder and 
Center controllers still have traffic in their sectors when the last flights of the arrival peak are approaching their 
landing runway. The third group of aircraft consisted of the departures leaving KPHX. Only departures leaving from 
the inboard runway were selected and included into the traffic scenarios. Lastly, the fourth group of aircraft included 
the over- flight traffic. These are flights departing and landing from airports other than KPHX. Any over- flight 
aircraft not interacting with the traffic in the test sectors was removed from the scenario, to minimize the amount of 
traffic the ghost controllers had to interact with. 

D. Airspace and Routes 

Figure 1 shows the test airspace including the test sectors with radio frequency and altitude strata labels, as well 
as the routes including the waypoints with altitude and speed restrictions. The simulation’s test airspace was 
comprised of three high-altitude sectors (37, 50, 93) and five low-altitude sectors (43, 39, 38, 46, 42) from 
Albuquerque Center (ZAB), four high-altitude sectors (40, 60, 36) one low- altitude sector (35) from Los Angeles 
Center (ZLA), and four Phoenix TRACON (P50) sectors; two feeder sectors (206- Apache, 212-Santan) and two 
final sectors (205-Freeway, 204- Verde). Additionally, the simulation was supported by several confederate ghost 
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Figure 1. Simulation Airspace showing the test sectors and adapted routes for west-flow configuration. 


controllers. The simulation was supported by several confederate ghost controllers: a departure ghost controller 
handled the departing traffic out of KPHX and the surrounding satellite airports, a satellite ghost controller handled 
the arriving flights into neighboring airports, a tower ghost controller controlled KPHX arrivals during the last few 
miles of the final approach until landing, and lastly two en-route ghost controllers (ghost high, ghost low) worked 
the substantial amount of remaining traffic in the surrounding airspaces. Real-world sector boundaries and altitude 
strata were used. Additionally, positions for a ZAB Traffic Management Coordinator (TMC) and a P50 Arrival 
Radar Coordinator (ARC), who also doubled as a P50 supervisor, were staffed. 

The recent, as well as upcoming CA studies will simulate both, west- and east-flow airport configurations. For 
both arrival directions, merging RNAV optimized profile descent (OPD) routes and non-RNAV routes (see 
Figure 1), were adapted based on existing Standard Terminal Arrival Routes (STARs) and Instrument Approach 
Procedures (IAPs). The adapted RNAV OPD routes were: MAIER5, EAGUL5, KOOLY4, and GEELA6. The 
adapted non-RNAV routes were: COYOT2, JESSE1, SUNSS8, and ARLIN4. 

III. Scenario Design 

This section provides a detailed description of the scenario design process as it was followed building scenarios 
for the current CA simulation series. The first part of this section offers insights on how real-world traffic has been 
identified and converted into raw traffic scenarios, the second part delivers an in-depth depiction of the how the 
traffic scenarios were then modified and matured to a state ready to be tested in a laboratory environment. The 
section concludes with a portrayal of the testing and evaluation cycle. 

A. Scenario Design Preparation 

7. Preparation of raw traffic data 

Recordings of live traffic were first obtained in a ‘cm-sim’ format used by NASA’s Center-TRACON 
Automation System (CTAS). 14 The cmsim files for each of the two traffic peaks covered the 24 hours of the 
respective day. These files were imported separately into TRAC for independent visualization, manipulation and 
traffic output. 

From the options provided in the TRAC Data Set properties (Fig. 2), aircraft were filtered into the four main 
aircraft groups: arrivals, extended-arrivals, departures and overflights. To form the selection of arrivals for example, 
several steps were included. First, the main data sets were filtered by the call-signs comprising the respective arrival 
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rushes. However, when working from cmsim data, 
a call-sign alone cannot be used to reference a 
unique flight because, as happens on occasion in the 
real-world, an arriving flight can re-use its same 
call- sign when it departs from the same airport. For 
these reasons, several levels of filtering were needed 
to properly identify the four main aircraft groups. 
The initial filtering by call-sign, for the west-flow 
data set, left a subset of 155 a/c (out of 4542 a/c 
overall). Further filtering by flight type (arrival 
traffic only) resulted in a subset of 79 a/c. Filtering 
by arrival runway reduced the number of aircraft in 
the set to 75 a/c. In order to filter out the remaining 
irrelevant aircraft, a manual search was necessary: 
flights with subsequent call-signs (e.g., AWE9 vs. 
AWE94) or duplicate call-signs (AMF2863_557 vs. 
AMF2863 559) were identified in the list of aircraft 
and, where appropriate, un-selected. 

The Data Set Flight Table (accessible via the 
aircraft tab of the Data Set Properties window) 
displays the filtered traffic data in a tabular fashion 
(Fig. 3). With 
the arrivals 
properly 
filtered, a 
time slider 
(found in the 
visualization 
tab), which 
allows the 
user to play 
out, fast 
forward, or 
rewind the 
traffic, was 
then moved 
to the point 
in time where 
the first 
aircraft of the 



Figure 2. TRAC Filter tab in the Properties window of a 
data set. 
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Figure 3. The TRAC Data Set Flight Table allows saving the information of the filtered flights 
in the TRAC or MACS scenario format. Note: only eight of 45 columns are shown. 


respective arrival rush was just outside of the respective TRACON meter fix. A link between the time slider and the 
flight table keeps the data in the table synchronized with the aircraft present at the selected and later times. For 
example, assume that a flight enters the playback (visualizing the first track-hit for that aircraft in the cm sim file) at 
1:00 a.m. If the time-slider is set to 00:00 a.m. the initialization time in the flight table will be set to 3600 seconds. 
But when the time-slider, for example, is set to 01:30 a.m. the initialization time in the flight table will be set to zero 
and its initialization position in the flight table will be set to the current position of the aircraft, opposed to the 
position where the aircraft first entered the replay. This ‘snap shot’ of the arrival traffic (their locations, their 
altitude, their flight plans, etc.), was exported as a MACS traffic scenario file. This process was repeated for the 
other main aircraft groups, with extra care taken to ensure that the time- slider was set to/kept at the same time that 
was chosen for the arrivals. This guaranteed that initialization positions of all the aircraft were in correct relation to 
each other. 


The exported traffic files contained mostly information that was available in the cm sim data, with specific 
columns for departure and destination airports, aircraft type, the filed route, altitude, initial latitude and longitude 
coordinates, the initialization time of the aircraft, etc. Where possible, other values were computed by TRAC using 
certain assumptions. For example, indicated airspeed (IAS) was computed assuming a no-wind environment and 
applying the International Standard Atmosphere (ISA) model. Some fields were set to a default values for all flights. 
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For example, a column for setting whether an aircraft was in Vertical Navigation (VNAV) was set to TRUE. Some 
fields however, cannot be assumed, such as an aircraft’s altitude target, and were either set to zero or 
‘_NOT_SET_\ These exported files were then opened in in the MACS scenario editor (Fig. 4), for further editing 
and manipulation. 



Figure 4. The MACS AC Table editor provides a spread-sheet style interface to the scenario content. Each 
flight is represented by one row. Cells in red were flagged by the automated error checking feature. Note: 
only 20 of 60 columns are shown. 


B. Main Scenario Design 

The next section describes the scenario editing actions that mature the raw traffic scenario to a state at which it 
can be taken to a distributed simulation environment in the lab for testing and validation. 

Before any scenario edits were applied a general decision had to be made, to which degree the raw traffic 
information in the scenario can be modified, and still meets the goal of capturing the original characteristics of the 
live traffic recordings as best as possible, while applying the least amount of changes. The cmsim data contains the 
recordings of live controlled traffic. Therefore, the various values for each flight in the raw traffic scenario represent 
the control actions of the controllers (delay vectors, temporary altitudes), but it is unknown exactly what the 
clearances were and why they were given. It was agreed, that the focus should not be on trying to edit the scenarios 
attempting to capture those control actions. On the contrary, the goal was rather to study the control actions of the 
test subjects, to answer the question how they would control the traffic. The implication of this decision for scenario 
development was that route, altitude and speed edits were accepted, where necessary, under the premise to stay as 
close as reasonably possible to the original values. 

1. Route Edits 

In MACS scenario files two route fields need to be defined. The data in the <filedRoute> column describes the 
route the ATC host system has available upon simulation initialization. The data in the <route> column describes 
what the FMS on the flight deck side knows; this is the routing the aircraft is ultimately flying. Those two route 
entries needed to be validated for accuracy so that MACS can parse them. The values were checked for correct 
syntax and any offending route tokens. 

The arrival and extended-arrival aircraft were assigned a nominal arrival route. In general, this meant that flights 
were assigned the appropriate route for the aircraft type category and equipage (i.e., jet/turbo, capable of flying area 
navigation (RNAV) routes), and were routed to the landing runway closest to the direction they came from. Traffic 
on the approach to KPHX from the north-west were assigned to either the MAIER5 (RNAV) or COYOT2 (non- 
RNAV) STAR, while arrival traffic from the north-east were assigned either the EAGUL5 (RNAV) or JESSE 1 
(non-RNAV) STAR. All aircraft from the north were assigned to the 26/08 runway. Arrivals approaching KPHX 
from the south-west were routed via either the GEELA6 (RNAV) or ARLIN3 (non-RNAV) STAR, and arrival 
aircraft from the south-east were assigned either the KOOLY4 (RNAV) or SUNSS7 (non-RNAV) STAR, all of 
which were assigned the 25L/07R runway. 
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Figure 5 and Fig. 6 use AMF2687 as an example. Besides listing 
any error for a flight record in the aircraft error list (cf. Fig. 4) MACS 
also provides details on detected errors when the mouse is hovered 
over a field that is highlighted in red font. 

Three delimiters are used to describe a route. A indicates that 
the next item is a fix. The means that the next item is not a normal 
fix but a named collection of fixes (or a part of that name). A defined 
name could be STARs, standard instrument departure (SID) routes, jet 
routes, etc. Their definitions are saved in MACS airspace adaptation 
files. The “/” is what is used as a convention to separate out the 
departure airport from the rest of the flight plan. The objective for the 
current design process is to have the <filedRoute> represent as much 
as possible the full pre-departure filed flight plan. The <route> column 
represents a truncation of the <filedRoute> including only route tokens 
that the aircraft will actually pass during the simulation. 

The black box in Fig. 6 shows the errors that were found for the 
<filedRoute>. In this case MACS does not know about the jet route 
J92 and about the STAR SUNSS7. MACS also does not accept 
duplicate entries. To fix those errors, first all entries for J92 were 
deleted. In this case the deletion of J92 did not impact the aircraft 
route, because the next downstream point from its initialization 
location is the fix TUS (cf. Fig 5). If the offending route tokens are 
downstream from the initialization position, and if their deletion 
impacts how the flight traverses the test sectors, then one attempt to fix 
the route is to replace them with the individual waypoints that 
comprise the named token. For example, if a flight is filed to use J72 
entering at ABQ and exiting at BLD (i.e., ..ABQ.J72.BLD..) and if J72 
happens to be unknown to MACS then it could be replaced with (some 
of) its waypoints (i.e., ..ABQ..LORAT..GUP..PGS..BLD (cf. Fig. 7). 

For arrival aircraft the adapted arrival routes begin in the high- 
altitude test sectors. Therefore, if a route token is unknown and has to 
be deleted, the route of a flight through the test sectors would change 
very little, if at all. Figure 8 shows an example. COA1707 is filed to 
fly KIAH./.JCT.J86.ELP.J50.SSO.KOOLY4.KPHX. Assume J50 is not known to MACS. If deleted, as it was done 
for COA1708, it would only bypass the waypoint ALIBY, and enter the test sector 90 just a bit north of where it 
would have originally. Again, the waypoints of an unknown route, ALIBY in this case, can also be entered 
specifically into the filed route. 



Figure 5. A graphical representation of 
the filed route for AMF2687. 


filedRoute route 


| MMHO./.XHMO.J92.VYLLA.J92.TUS.SUNSS7.KPHX ..XHMO. .J92..VYLLA. .J92..TUS..SUNSS7.. 


J92 not found J92 not found SUN5S7 not found J92 is duplicated 


MMHO./..VYLLA..TUS.SUNSS8.KPHX ..TUS.SUNSS8.FINAP.ILS25L 


Figure 6. The MACS error feedback feature provides pointers on which route elements are erroneous. 

If MACS reports an error about duplicate entries, as shown in the example of AMF2687, the one entry that is 
closest to the origin airport was deleted, as it most likely does not affect how the aircraft is actually flying through 
the test sectors; the graphical representation of the <filedRoute> in the Scenario Editor provides an easy way to 
verify the route. In the example J92 is unknown to MACS and so all J92 tokens were deleted. 

The last token that is labeled as an error in the example above is the STAR SUNSS7, because the MACS 
adaptation listed this STAR under a custom name (SUNSS8), which was a modified STAR in support of ATD-1. In 
other cases STARs may get flagged as error because they were not adapted (for example for airports other than 
KPHX), or the actual published routes were updated and received different name since the recording date of the 
cmsim data. Because AMF2687 is initialized close to TUS and flies straight towards it (cf. Fig. 5), the fix VYLLA 
(behind of the aircraft initialization position) is removed from the <route> entry. Individual cells or entire columns 
can be set to be auto-update depending on the entries in other columns. The <targetWaypoint> column was set to 
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Figure 7. Jet route J72 connects the navaids and fixes ..ABQ..LORAT..GUP..PGS..BLD 



Figure 8. The lateral impact on a flight path when omitting a route element. COA1707 and COA1708 have 
identical filed routes except that for COA1708 after the navaids ELP the jet-route J50 was omitted. 


auto-update, with a dependency linking it to the <route> column. Therefore, the update of the <route> for AMF2687 
automatically triggered the correct waypoint name to be entered into the respective <targetWaypoint> cell. 


2. Initialization Point and Altitude Edits 


To provide the desired realism for the upcoming ATD-1 simulations, a key aspect of the scenario design was to 
closely match real-world traffic situations. Because the ATD-1 project is focusing on arrival operations, the initial 
flight state of the arrival traffic to KPHX in the scenarios needed to model the respective flight state of the raw 
traffic as close as possible. Therefore, the initialization latitude and longitude values, and initialization times of the 
flights of the peak arrival rush and the additional arrivals were kept constant in the scenarios, even if the 
initialization position of the flights were off-route. Because the flights were initialized in VNAV, they generally 
were back on their route quickly. Some aircraft were exempt from this constraint. Those special cases are explained 
in section III.B.4. 

Retaining the actual initialization positions for over- flight traffic was less critical, as long as the interactions with 
the traffic streams in the test sectors were not altered significantly. The initialization positions of the over-flight 
traffic were adjusted to align with the respective filed route. 

The altitudes of the arrivals and extended arrivals were kept constant also, with few exceptions. Values were 
modified if they did not comply with the direction of flight or if they needed to be rounded to the nearest flight level. 
Because the cruise altitude and target altitude fields were set to auto-update, they were modified when the respective 
altitude value was edited. The cruise altitude of some flights, especially those not in cruise upon scenario 
initialization, was verified by bringing up the respective trajectory profile in TRAC. For flights in cruise, before top 
of descent (TOD), all three altitude values matched. For flights in descent the altitude target, that is, the altitude to 
which the aircraft will climb or descend after initialization, was set to the first downstream altitude restriction. For 
all flights but the departures value in the start point name column was auto-updated based on the values in the 
latitude and longitude column. For the departures the start point name was set to the name of the respective 
departure runway; the latitude and longitude values were filled in automatically. Exceptions were flights that 
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departed KPHX but were airborne already. The altitude values for the departures that were still at KPHX at their 
initialization was set to the runway altitude, and their altitude target was set to their cruise altitude. 

The initialization points of over-flight traffic were eligible to be modified. Over-flights were moved onto their 
filed route using an automated function. For some aircraft the flight path would change significantly. In order to 
avoid that, an additional (published) waypoint before the initialization position was inserted into the filedRoute. 
After moving the flight onto its filed route it remained close to its original initialization position. 

3. Speed Edits 

The next scenario building step was to update or correct the speed values of the flights. The decision making 
process on which speeds needed to be set to which value is depicted in the flow chart in Fig. 9. The IAS and the 
Mach number are directly linked to each other; editing one value in MACS will set the other one to be auto-updated. 
The <inMach> column indicates if a flight is flying mach speeds upon initialization. The AC Table editor will set 
the cells in this column to true if the aircraft is higher than 29000 ft. 

For flights in cruise a typical cruise mach numbers or, if lower than 29000 ft, a typical cruise IAS was used 
(often internet lookup). Both the speed target, which is the speed to which the aircraft will accelerate/decelerate after 
initialization, and the cruise speed values were set to the same value for aircraft that are initialized before their top of 
descend (TOD). Descending flights would get assigned a typical cruise mach number if they were higher than 29000 
ft. If they passed that altitude already they would get assigned a typical cruise IAS, unless they are already past a 
waypoint with a speed restriction. In that case, the flight would get assigned the IAS of that restriction; the speed 
target value was set to the next downstream speed restriction. Departures that are still on the ground at KPHX got 
assigned an IAS of zero. The IAS of KPHX departures that were initialized airborne and are in their climb phase 
was set to their climb speed (the <climbSpeed> column was set to auto update). Their speed target value was set to 
their cruise speed value. 


s 



OT 

e 

mach s 

typical cruise M* 

IndicatedAirSpeed = 
typical Cruise IAS* 



mack ~ 

typical cruise M 


indicate dA i rSpeed - 
typical cruise IAS 


* - speedTarget = cruiseSpeed 

Figure 9. Decision tree for assigning the indicated air speed and mach values 


IndicatedAirSpeed = I i n aicatedAlrSpeed = I IndicatedAirSpeed -- 
Previous speed I „ c | im bs pe ed 

restriction IAS ■ m 


Later in the scenario design process the speeds were updated using a different speed assignment strategy. MACS 
supports the use of cost index (Cl). It is used for various trajectory computations. The Cl is a factor that indicates the 
balance between speed and fuel efficiency. A Cl of 999 gives speeds as fast as possible without consideration of 
fuel, while a Cl of zero gives maximum efficiency. 

The Cl in MACS is used in the scenario editor to compute the cruise, descent and climb speeds. Together with 
the altitude all other altitude and speed values were updated automatically and the manual lookup of typical speeds 
and altitudes was rendered obsolete; using the Cl all values were computed by MACS. The approach speed and 
landing speed values were kept at 140 kts and 120 kts, respectively. The MACS auto-fix function was applied if 
those values were flagged as error. Before setting a Cl value however, the auto update references of the various 
columns had to be verified. The diagram in Fig. 10 is explaining the selected auto update dependencies. A Cl of 100 
is commonly used by the airlines. Setting the Cl to this value provided typical speed values. 
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4. Moving initialization positions into ZLA 

Cmsim data is recorded for each Air Route Traffic Control Center (ARTCC). Because KPHX is on the west 
side of ZAB (cf. Fig. 1) the first traffic state data available is just before the Center boundary. This meant that traffic 
was initialized inside the ZLA test sectors and/or just outside the ZAB high-altitude test sectors leaving little to no 
time for the controllers to condition those flights before they enter their airspace or, before they needed to be handed 



Figure 10. Auto update dependencies of the MACS AC Table Editor set during current scenario 
development process. 


off to the next sector. Consequently traffic entering ZAB airspace from the west was backed up into ZLA airspace. 
The cm sim files from ZLA for the respective traffic days were used to obtain the flight plan and state information 
for the various flights that needed adjustment. 

Because CIDs are re-issued in every Center, it was not possible to use a call-sign-CID combination to create a 
unique identifier to find exact matches for the flights of the ZAB and ZLA cm sim data files. TRAC was used to 
parse out of the ZLA cm sim file flights with matching call-signs. In a second step MS Excel was used to lineup the 
flights using the origin and destination airport information. The flight plans from the ZLA cm sim file were then 
copied over the corresponding flight plans in the existing traffic scenario files which were created based on the ZAB 
cm sim files. The filed route and route entries were checked again for errors and updated as described above. 

Next, the flights entering ZAB from the west with an initialization time greater than zero were moved along their 
filed route (using the Move Aircraft function in MACS) towards their origin airport into ZLA airspace. The goal of 
this scenario editing step was to do this in such a way that the resulting traffic situations resemble the original 
situation from the ZAB cm sim file as close as possible. This meant that, if the traffic was not controlled by 
controllers, the aircraft should be at the same simulation time at their original initialization positions. For example, 
assume a flight was moved back a distance along its filed route that equates to 500 seconds of flying time. The 
aircraft now needs to be initialized 500 seconds earlier in order for it to be at its original initialization position at the 
original simulation time. 

After the fights were moved, their start point name and latitude and longitude coordinates were updated 
accordingly. Also the altitude, altitude target and possibly the cmise altitude were updated if an aircraft was backed 
up to a position before its top of climb (TOC). Those altitude values were checked if they comply with the direction 
of flight, up- and downstream restrictions, and whether or not they needed rounding. In a second step, the 
initialization times of the aircraft were reduced such that the flights arrived at their original initialization positions at 
the same simulation time. 

Caution had to be used to not back up a flight over a distance that corresponds to a flying time greater than the 
initialization time. With Zero being the earliest possible initialization time, this would result in the aircraft being at 
the reference point at a different time. If an aircraft was off-route initially, moving an aircraft along its filed route 
will put the aircraft back onto it. This means that not all original initialization positions as imported from the ZAB 
cm sim raw data were maintained. Other traffic that entered the simulation close to the test sectors was backed up 
from the original initialization locations, too. The same strategy as described above was applied. 
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5. Sector Assignments 

In a last step of the main scenario editing sector ownerships were assigned to the flights. Two columns in the 
scenarios that is, <ctasSectorId> and <acSectorId>, define the sector assignments. <ctasSectorId> indicates the 
sector that has track control of the aircraft when it gets initialized. <acSectorId> indicates the pseudo pilot station 
linked to this sector, that will have ownership of the aircraft. The <acSectorId> was set to be auto-updated by the 
<ctasSectorId>. Initially, all aircraft were assigned to the Ghost High sector. Then, using the map view of the 
Scenario Editor the aircraft inside and just outside of the test sectors were selected and assigned to the respective 
sector number if their altitude was less than the Ghost High floor altitude. Cross-checks of the altitude values against 
the sector floor indicated flights that had to be assigned to the Ghost Low sector. Lastly, flights assigned to the 
Ghost High sector with altitudes lower than the sector floor altitude were assigned to the Ghost Low sector. Any 
flights that have one of the P50 satellite airports as their destination were assigned to the Satellite Ghost controller. 
Any departures out of KPHX or out of any of the satellite airports were assigned to the Departure ghost controller. 

6. ASTOR Scenario Design 

The AOL has the capabilities to simulate eight high-fidelity single pilot stations. The ASTOR simulator stations 
from NASA Langley were integrated with the MACS simulation environment. Flights operated by the ASTOR 
simulator needed strategic placement in the arrival sequence, and required careful coordination between two file 
formats: that of the MACS traffic scenarios, and the specific ASTOR scenario format. 

As a first step candidate ASTOR flights were identified in the east- and west-flow MACS scenarios. Because the 
ASTOR aircraft performance model that is recommended for HITL studies emulates the characteristics of a Boeing 
B757-200 (B752) aircraft, flights using this aircraft type were primary ASTOR candidates. Other aircraft types of 
the same weight class (e.g., A321, B738, etc.) were also emulated reasonably well using the B752 performance 
model. Additionally, other constraints had to be met: candidates had to land within one hour of simulation time and 
needed to be initialized before their TOD. 

In the east- and west-flow traffic scenario two KPHX arrivals were B752 aircraft. Several other ASTOR 
candidate flights in each scenario were identified complying with the aforementioned constraints. Table 1 lists the 
flights that were ultimately selected as 
ASTORs. 

In the next scenario editing step key 
aircraft values from the eight ASTOR 
flights in each MACS scenario were 
copied to the respective ASTOR scenario 
file. Those values included call-sign, 
latitude, longitude, true heading, mach 
number, altitude, origin, destination, 
cruise altitude, climb Speed, descent 
speed, cost index, aircraft type, filed 
route, target waypoint, and beacon code. 

Before copying those values, however, 
the aircraft type of the six additional 
ASTOR candidates in MACS were set to 
be B752 aircraft to account for the B752 
aircraft model used for the ASTOR 
simulators. The weight was set to a 
common cruise weight of 194000 lbs. As 
a result the speed values of those flights Table L ASTOR flights selected for east- and west flow 

were updated automatically (cells were configuration. 

set to auto-update). The mach values of 

all ASTOR candidates were rounded to have two digit decimals. 

Figure 11 shows an example snippet of an ASTOR scenario file. The entries from line 1-23 define database 
references (routes and airspace), wind file references and define values that are needed to interact with MACS (e.g., 
the name of the MACS scenario bundle). Lines 26-54 show the entries that define the current and future state of one 
ASTOR flight, where line 27 defines the initialization state of the flight. Line 33 references the name of a company 
route (KLASKPHX01) that determines which route the aircraft will actually fly. Some default company routes are 
provided by the ASTOR system, but in order to retain the original routing from the MACS scenario, custom routes 
were added. 


East-flow 

<callsign> 

<filedRoute> 

<acType> 

AWE119 

PKOA./. FOOTS.. FICKY..SXC..TRM..BLH.GEELA6. KPHX 

B752 

AWE125 

PHNL./.EDSEL..ELKEY..LAX..TRM..BLH.GEELA6.KPHX 

B752 

AWE3 

KLAX./.TRM.J 169. BLH.GEELA6. KPHX 

A321 

AWE158 

KLAS./.PRFUM.MAIER5.KPHX 

A319 

AWE271 

PANC./.WINEN..CORKR.MAIER5.KPHX 

A319 

AWE54 

KMCI./.ALS..GUP.EAGUL5.KPHX 

A321 

BSK610 

KCID./.RSK.J 161. ZUN.EAGUL5. KPHX 

B738 

AWE265 

KBWI./.LBL..WILPA..ZUN.EAGUL5.KPHX 

A319 

West-flow 

DAL2021 

KDTW./.GCK..CIM..ZUN.EAGUL5.KPHX 

B752 

N610G 

PHNL./.EDSEL..ELKEY..LAX.J96.YCDIL.J50.BLH.GEELA6.KPHX 

B752 

AWE500 

KLAX./.TRM.J 169. BLH.GEELA6. KPHX 

A320 

AWE197 

KSAN./.IPL.J18.MOHAK.GEELA6.KPHX 

A321 

AWE152 

KGEG./.WINEN..CORKR.MAIER5.KPHX 

A321 

AWE34 

KPDX./.WINEN..CORKR.MAIER5.KPHX 

A321 

AWE191 

KPHL./.LBL.J19.FTI.J244.ZUN.EAGUL5.KPHX 

A321 

UPS2876 

KSDF./.CIM..ZUN.EAGUL5.KPHX 

B763 
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Some AS TOR flights had an original 
initialization time greater than zero. To 
have all ASTOR stations initialize at the 
same time and, in order to avoid a long 
wait time for pseudo pilots the respective 
ASTOR aircraft in MACS were backed 
up along their filed route the appropriate 
amount and their initialization times were 
set to 120 seconds (cf. to Footnote |t)- 
The initialization latitude, longitude and 
time values were then copied from MACS 
back to the ASTOR scenarios. 

When running the scenario in a 
human-in-the-loop mode together with 
MACS, the ASTOR and MACS traffic 
scenarios get initialized and launched at 
the same time and play in parallel. To 
avoid having duplicate flights with the 
same call-signs on top of each other, the 
first letter of the call-signs of the ASTOR 
flights in the MACS scenarios were 
replaced with an ‘X’ (e.g., AWE158 -> 
XWE158). Additionally the 

<entryTimeSeconds> were set to a very 
high value (e.g., 55555) to move the 
aircraft out of the simulation, but to keep 
them as “dummies” in the traffic files for 
future scenario edits. 

C. Scenario Testing and Validation 

Before testing the scenarios in a 
distributed lab configuration the 
individual scenario files for arrivals, 
extended arrivals, departures and over- 
flights were merged into one single traffic 
scenario file. After the merge a built in 
MACS scenario editor function was used 


: t ScfiMEi&lBitFile : 

□OiflO:30.oa>MJtvnaTAaaaE cas_ismov-iojm- 2[M3 

4 00:00:00, O0>MAVDATABA3E TILE CE1 

5 00 ; DO : DO . 00>!UV1]»ABA3E 1 HI* KHH£_Riry 07RO8_datai«Be_ini t ial Lotion 

e 

7 * Winds 

00 : 00 : 90 . 00 >w INDPREE-3 CTED aAH_2O110430_10z_EaBt_ForeeMt 
9 00 : 00 : DO . 00 >W ENDTRtTTH ZAB_201 104 30_07i_£Mfc_f ruth 


11 t MACS items 

12 tOO:00:00.00>MACaHATABA3E PHX 

13 *O0;OOiOO,OO>MAC3EXPERIHEMT CA5-1 

14 OOi 00 1 DO , 00 >HAC3COff FI G CA5-1 

15 00 1 00 1 00 . 00 s-hacshundle. Bundles /Data col leet iont 2013071 5^Jtetnc&llectieri_Run01_Ei . a can* i 

18 00; 00: 00. DO^MACSMAMAGER 

17 00 : 00 ±00.00 >HAC3CONTROL1ER 3 

10 

19 I Miaic Stuff 
00:00:00. 00>LOG2 F2 LE 

21 | 

23 01: 30:00. 00^1* 

24 ntnttttttututtttt 


25 
28 
27 

26 

29 

30 

31 

32 

33 

34 

35 

38 
37 
33 

39 

40 

41 

42 

43 

44 

45 
48 
47 
40 


f HA3A4 


00:02:00. 00 >CRE AWE158 NASA CMF, 35.B27A1S, -114.61434, 124fl, 29000, 0,78 
00:02:00, OOAWE153 A33IGH XStOM 
00:02:00. 0O> AWE 158 F9LACT¥2E A319/Q 

00: 02 :Q0, 00>AHEl5S RATE_GF_CLIMB O 


00:02:00. 00>AWE15S 
00:02:00. 00> A»E 153 
00: 02:00, 0Q>AWEl5B 
00: 02 :Q0.O0>AWEl53 
00 : 02 : Q0 . 00 > AWE 153 
00:02:00. 00 >AWE 150 
00: 02 :D0* 0O>AWEl53 
00:02:00. 00>AWE15B 
OO:O2:OO.OO>AWE150 
00: 02:00. DOAWE15& 
00:02:00. 00 > AWE 1 5 & 
00:02:00. 00>AWE15B 
00:02 :00.00>AHEi5e 
00:02:00. 0 Q >AWE 153 
00:02:00, QO> AWE 1 5 & 
00:02:00, 00 >AWE 153 
00:02 :00.00>awe15& 
00:02:00. DO> AWE 153 


GR09SNT 194000 

2EROEUELWT 170000 

COfiGttTE KUV3KPHX01 PRFU H 

GRIG KIiAS 

DE3T KP HX 

XPDR 14B4 

DEA1DNALT 3400 

MCPAL* 29000 

CRB ALT 29000 

ZLB3PD 279 

DE3SPD 0.76 

P1LOIMODEL NORMA! PM _HANUAL \MA_3PD_ WINDOW 

COaTIWDEX 100 
fccpetchmom; vnav 

FCCRDCLIMODE I.MAV 

EQUIPASECONFEG E^ip*0*Config_PIRAT 
EHABE-EPOSOISP^AVa TRUE 
ENABLE FMHCDUBUTTQN TRUE 


00 : 02 : DO . 00 > AWE 1 S 0 

50 0D: Q2 : 00. 0OAWE153 

51 00: 02 :00, 00>AHEE53 

5 2 00:02:00. Q0> AWE 1 5 B 

53 00:02:00. 00 >AWE ISO 

51 00:02:00. 0O>AWE 153 


AOPCQNFIG AQP_KAKAGED 
T CAS CONFIG TCAS_for_PIRAT 
AT3ECONF1G ADSa_PIRAT 
PD3C0N FIG PM_f or_P 1 fUT 
RADI C5CONFI G RadioDef aul C 
rPLROUTE F-LAS . / , PP.FUK. HA1ER5 . EPHX 


Figure 11. Snippet of a ASTOR scenario file. 


to probe for any aircraft that are in conflict upon initialization which would leave the controllers no chance to 
prevent it. After this scenario editing step the scenarios were in a state ready to be tested in lab sessions and 
simulation shakedowns to gain further controller feedback. 

Several lab check-out sessions with researchers only, multiple full-day simulation shakedowns with retired 
controllers and pseudo pilots, and a full-day meeting with subject matter experts (SME) (i.e., two recently retired 
P50 controllers) provided valuable insights into the operations of P50 and uncovered a number of issues. Before 
applying further changes and fine-tuning the scenarios a change control procedure was put into place that kept track 
of the modifications in the MACS and ASTOR traffic files. 


Several important changes were applied to the scenarios after the shakedowns and SME feedback. It was decided 
to simulate the P50 operations with the north-western Military Operations Area (MO A) around Luke Air Force Base 
active. This means that the filed route and route entries for all flights crossing that area had to be changed so that this 
area was not penetrated. Controllers also explained other special use airspace (SUA’s) regions around KPHX that 
had to be taken into consideration. The cmsim traffic data does not include any information whether or not a SUA 
area was active or not. The only indicator was if flights were penetrating those regions or not; the reason however 
were unknown. For the scenario design process and the simulation conduct the following was decided: re-route 
flights that cross main SUA areas that are active almost all the time. Keep the routing of flights that cross other SUA 
areas the same. They were considered inactive. Flights that initialize inside a SUA area were considered to have 
special permission to penetrate that area; no control action to move the flight out of that area was necessary by the 
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test subjects. Figure 12 shows the test sector outlines in black and the SUA areas that were considered active with a 
grey shading. Other SUAs are outlined in red. 

KPHX SMEs also pointed out the routing that Group C (Table 2) aircraft typically get assigned. 7 * * * * * * * 15 Usually they 
are handled by the satellite arrival sectors who 
issue control vectors via specific waypoints and 
do not use any of the RNAV or non-RNAV 
routes. The routes of the Group C aircraft in the 
scenarios were checked for correct routing and 
were adjusted if necessary. Furthermore, the 
SMEs pointed out that certain aircraft types that 
were used in the traffic scenarios were not able 
to fly RNAV operations. Those aircraft types 
were simply replaced with similar performing 
types that are RNAV capable. For example, 

CRJ2 aircraft were replaced with CRJ9 aircraft. 

Initial shakedowns revealed that the initial choice of north/south Ghost Controller split did not work very well. 
The flight data blocks from the aircraft in in ownership of the ghost controllers would clutter their scope too much. 
The Ghost High/Low sector split was set up instead. The sector ownerships of the affected aircraft were updated 
accordingly. Other flights were pointed out by the controllers that suddenly popped up in the sectors. When looking 
at those flights more closely it became clear that they were mostly departures from satellite airports that climb 
through the floor of the sectors and should get handed off from the Ghost Low controller. 


Group Aircraft type 


Group A 

Turbojets (except EA50, C25A/B, E50P, and 
C500-C551 series aircraft) 

Group B 

Turboprops (except C208, DHC6&7, P46T and 
T34T and BE99), EA50, C25A/B, E50P, and 
C500-C551 series. 

Group C 

All other aircraft and C208, DHC6&7, P46T, 
T34T and BE99. 

Table 2. 

Aircraft groups as defined in the Albuquerque 


ARTCC and Phoenix TRACON Letter of Agreement 



Figure 12. Restricted airspace regions around KPHX. 

7. Little gotchas with big impact 

Throughout the main scenario design process and during testing several small errors and problems occurred that 

affected just a few aircraft but had a larger impact on the whole system; other flights were impacted and therefore 

controller workload. While some of the errors could be fixed or workarounds could be found by edits in the scenario 

file itself others would require software changes. In this section two examples are described. 

During tests it was noticed that a few arriving flights would descent to their first altitude restriction well ahead of 
the respective waypoint. Once the flights passed it, they would climb back up to the cruise altitude until descending 

again. Other flights with a cruise altitude lower than the first altitude restriction would climb to meet this restriction 
opposed to staying level until intercepting the vertical path downstream (target altitude and cruise altitude were set 
to the same value as the (current) altitude). In both situations the solution that prevented this behavior was to set the 
<inVnav> fields in the AC Table Editor to false and have the aircraft fly in flight level change (FLCH) mode. 
Pseudo pilots were briefed to switch the flight mode for those aircraft back to VNAV at the appropriate times. 
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Tests also revealed that aircraft that land into the Albuquerque International Sunport Airport would descent, but 
then get stuck at a very low altitude (about 1600 ft). The flights would not get deleted from the simulation and kept 
flying indefinitely. Debugging showed that the MACS software confused the destination airport, listed in FAA 
format (i.e., ABQ), with the Very High Frequency Omni-directional Radio-range (VOR) of the same name. A 
software update allowed MACS to recognize airport names following the ICAO naming convention. The filed route, 
route, departure and destination airport entries were updated accordingly. An automated function in MACS assisted 
with those edits. 

D. Scenario versions 

In preparation for the most recent CA experiment several data collection and training scenarios were created by 
using the two original east- and west- flow scenarios as templates. Besides the two original scenarios three additional 
data collection versions per airport flow configuration needed to be generated to be simulated in four wind 
environments per arrival direction. To minimize learning effects the call-signs for each flight for each version were 
modified. TRAC provides an automated function that generates new call- signs for a loaded data set. The function 
will retain the airline portion of the call-sign, as well as the length of the number string while keeping the first digit 
the same. 

For controller training, scenarios with a reduced traffic load were needed initially. One third of each traffic group 
was deleted from the two original scenarios. The call-signs were randomized four times for each arrival direction to 
generate versions for the four wind sets. Finally, in order to further minimize learning effects a small random value 
was added to the initialization times of the arrival and extended-arrival flights which caused the scenario to play out 
slightly different. Later in the controller training, the same traffic loads as in the data collection runs were simulated. 
To generate scenario versions for those later training runs the two original data collection scenarios were used, and 
the randomized call-signs from the thinned training scenarios were applied. Additionally, new flight initialization 
times were generated the same way as described above. 

Finally, the controllers were supposed to work at least once one of the data collection scenarios to possibly 
uncover any last scenario problems. To reduce learning effects the call-signs for each flight were randomized once 
more. All scenario versions were subject to the change control procedure. 

The first data collection runs showed that controllers were getting increasingly better in controlling the traffic, 
and consequently their workload was getting lower. To counteract this trend it was decided to insert additional 
flights into the arrival rush period of the scenarios. For the east-flow scenarios six additional flights were added, for 
the west- flow scenarios five additional flights were added. All added flights were duplicates of jet aircraft on the 
RNAV routes. The remaining runs were sufficient to fill a complete data collection matrix with each of the eight 
scenario versions simulated once. 


IV. Results 

This section uses the east-flow traffic scenario to describe example results of the scenario design effort. The 
scenario building effort required approximately three months to complete, spanning the time from when the traffic 
days were chosen until simulation conduct. At times, several people worked separately on the traffic files, helping to 
finish the scenarios in time. 

The east-flow scenario (without the additional six flights introduced later on) contained 338 flights. Figure 14- A 
shows the ratio between the four different flight categories, arrival peak members (ARR), extended arrivals 
(ARR-EXT), departures (DEP) and over-flights (OVR). The chart in Fig. 14-B shows all aircraft types of the 69 
flights in the arrival rush. The most frequently used types are Boeing B737, Airbus A320, and Airbus A3 19, and 
Bombardier CRJ9 aircraft. 

Figure 15 shows the lateral positions of the peak arrival and extended- arrival flights at the start of the traffic 
scenario in blue, with the respective original traffic at the correlating point in time of the raw cmsim data file in 
red. It shows a near perfect alignment of the raw and simulated traffic in ZAB. The initialization positions of these 
arrival flights, with few exceptions, have not been altered. On the contrary, arrival flights from ZLA have been 
backed up along their routes to avoid having flights pop up inside the ZLA test sectors. Therefore, those flights do 
not lineup initially. 
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Figure 13. Selected metrics for the east-flow traffic scenario. A) Ratios of arrivals, extended arrivals, 
departures and over-flights. B) Aircraft types of the 69 aircraft comprising the arrival push 



Figure 15. Deviation in lateral aircraft initialization position between the east flow cmsim raw traffic (in 
red) and the scenario traffic (in blue). The time stamp at which the traffic was sampled from the ZAB 
cm sim raw traffic file was 9:30:02 UTC (cm sim) which correlated to 120sec simulation time in the traffic 
scenario. 


V. Conclusion 

Two base traffic scenarios, including several versions for controller training and for different wind conditions, 
have been created. The design process was greatly characterized by manual scenario modifications, although the 
MACS’ built-in scenario editor provided a wide array of automated editing functions, such as error checking, auto 
propagation, aircraft conflict indication, flight position alteration, etc. The complexity of the scenarios was relatively 
high due to the variety of traffic types included and the restricted ability to modify aircraft initialization positions 
and routing. 

The scenarios were used during the most recent CA HITL simulation and are expected to be used, as-is, during 
the upcoming simulations. The traffic files serve as a core template for other HITL studies of the ATD-1 effort, but 
are expected to be modified only minimally in order to allow direct comparison of simulation results as much as 
possible. 

The experiences gained during the scenario design process helped to identify further possibilities to improve the 
MACS scenario editor. For example, scenario building would be much easier if the editor could know the airspace 
and route adaptation (STAR-transitions, STARs, approaches, SIDs) that is used during the simulation. Also MS 
Excel-like multi-layer filtering functions would be a very powerful addition to MACS’ AC Table Editor. 


15 

American Institute of Aeronautics and Astronautics 


In addition, it became obvious that an early in-depth familiarization with the airspace and its operations is 
essential. Specifically, understanding published operating procedures and letters of agreement, studying maps and 
recorded traffic, is crucial. Discussions with subject matter experts familiar with the selected site are invaluable and 
should be performed early. Actual field visits can and should complement the pool of information consisting of the 
sources just mentioned. 
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